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I. Real Party in Interest 



The real party in interest for the present application is Convergys CMG Utah, the 
assignee of record, which is a wholly owned subsidiaiy of Convergys Corporation. 
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II. Related Appeals and Interferences 

There are no prior or pending appeals, judicial proceedings or interferences known to the 
appellant which may be related to, directly affect or be directly affected by or have a bearing on 
the Board's decision in the pending appeal. 
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III. Status of Claims 

Claims 1-20, which were rejected in an office action mailed September 27, 2010 (the 
"Office Action"), are the subject of the present appeal, and are set forth in the Appendix to this 
appeal brief. 
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IV. Status of Amendments 

There have been no amendments to the claims or specification filed after the Office 

Action. 
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V. Summary of the Claimed Subject Matter 

In general terms, the applicants' disclosure relates to technology which can be used to 
capture usage details for web services. This technology can be implemented in systems which 
not only capture usage details for web services, but which also authorize the same. A concise 
explanation of the subject matter claimed in each independent claim, with references to the 
specification by page and line number, and references to the drawings by reference characters, is 
set forth below. There are no independent claims or separately argued dependent claims which 
include limitations set forth in means plus function form. 

Claim 1 is directed to a computerized method for billing for web services. As recited in 
claim 1, that method comprises steps of creating a descriptor file designating a pre-defined 
element, and storing the descriptor file in a tangible computer readable medium. 1 The method of 
claim 1 also includes configuring a handler which is resident on a computer comprising a 
processor operable to execute computer readable instructions to monitor a web service network 
communication, between a service requestor and a service provider, for the pre-defined element 
in the descriptor file. 2 In the method of claim 1, the handler is also configured to send the pre- 
defined element to a set of programmed instructions to create an event record. 3 Claim 1 
specifically recites that the set of programmed instructions is configured to copy the pre-defined 
element from the network communication into the event record, 4 and that the event record is 



1 A descriptor file, and its creation and storage, are described in various places in the application, including lines 2-6 
of page 12, lines 3-8 of page 17, lines 17-22 of page 21, lines 1-12 of page 24, lines 21-25 of page 40, and lines 2-3 
of page 46. The descriptor file is also illustrated as the WebSvcUsageDescriptor in figure 2, and 
WebSvcDescriptor.xml in figure 15. A simplified textual example of a descriptor file is provided between line 13 of 
page 24 and line 1 of page 25, and a standard XML DTD and schema that describes a format which can be used for 
a descriptor file is provided between line 7 of page 41 and line 17 of page 45. 

2 A handler, its configuration, and the monitoring of a web service network communication, are described in various 
places in the application, including lines 6-10 of page 12, lines 14-15 of page 22, lines 2-20 of page 23, lines 8-12 of 
page 25 and lines 13-15 of page 31. 

Sending a pre-defined element to a set of instructions, as well as the creation of an event record, are described in 
various places in the application, including 22-24 of page 11, lines 10-12 of page 12, lines 14-18 of page 25, lines 
22-29 of page 3 1 and lines 22-28 of page 33. The section on "Event Composer Methods" set forth between line 1 of 
page 34 and line 19 of page 35 describes methods for the set of programmed instructions (e.g., an event composer) 
which creates the event record. Illustrative interfaces for an event composer are set forth between line 25 of page 35 
and line 4 of page 40. 

4 The copying of pre-defined elements into an event record is illustrated in the discussion of the event composer 
referenced in the previous footnote. The event composer is discussed at various points in the application including 
(as set forth in the previous footnote) in the section on "Event Composer Methods" set forth between line 1 of page 
34 and line 19 of page 35. 

7 



electronically transmitted to a billing system for further processing. 5 Finally, claim 1 states that 
the handler which is configured to monitor for the pre-defined element is located at the service 
requestor or the service provider, 6 

Claim 16 is directed to a tangible computer-readable medium having computer 
executable instructions for performing a method. As set forth in claim 16, that method 
comprises receiving a descriptor file designating at least one pre-defined element, 7 using it to 
monitor a web service network communication for the pre-defined element(s) from the descriptor 
file, 8 and copying the pre-defined element(s) from the network communication into a record. 9 
Claim 16 also recites that the method includes electronically sending the record to a billing 
system for further processing. 10 

Claim 17 is directed to a system for billing for web services which comprises a descriptor 
file, a handler, a record and a billing system. As set forth in claim 17, the descriptor file 
designates at least one pre-defined element. 11 The handler is configured to monitor a web 
service network communication between a service requestor and a service provider, and to 
intercept that communication if it corresponds to the at least one pre-defined element in the 
descriptor file. 12 Claim 17 also specifies that the handler is further configured to copy the pre- 



5 Transmitting an event record to a billing system for further processing is described in, among other places, lines 
12-13 of page 12, lines 17-18 of page 25, lines 4-8 of page 31 and lines 10-14 of page 32. 

6 This is disclosed in, among other places, lines 16-26 of page 16, lines 13-14 of page 22, lines 10-16 of page 23, 
and lines 1-3 of page 31. The location of the handler at the service provider or service requester is illustrated in 
figure 13 with the "Client Platform" and "Server Platform" components. 

7 A descriptor file designating at least one pre-defined element is described in various portions of the specification, 
including lines 2-6 of page 12, lines 3-8 of page 17, lines 17-22 of page 21, and lines 1-12 of page 24. The 
descriptor file is also illustrated as the WebSvcUsageDescriptor in figure 2, and WebSvcDescriptor.xml in figure 15. 
A simplified textual example of a descriptor file is provided between line 13 of page 24 and line 1 of page 25, and a 
standard XML DTD and schema that describes a format which can be used for a descriptor file is provided between 
line 7 of page 41 and line 17 of page 45. 

8 Monitoring a web service network communication for a pre-defined element in the descriptor file is described in 
various portions of the application, including lines 11-13 of page 13, lines 2-20 of page 23, lines 1-10 of page 24, 
lines 8-15 of page 25 and lines 13-15 of page 31. 

9 Copying the pre-defined elements into an event record is described in various portions of the application, including 
lines 13-14 of page 13, lines 1-3 of page 17, lines 9-18 of page 25, lines 1-2 of page 26, and lines 3-14 of page 32. 

10 Transmitting an event record to a billing system for further processing is described in, among other places, lines 
12-13 of page 12, lines 17-18 of page 25, lines 4-8 of page 31 and lines 10-14 of page 32. 

1 1 A descriptor file designating at least one pre-defined element is described in various portions of the specification, 
including lines 2-6 of page 12, lines 3-8 of page 17, lines 17-22 of page 21, and lines 1-12 of page 24. The 
descriptor file is also illustrated as the WebSvcUsageDescriptor in figure 2, and WebSvcDescriptor.xml in figure 15. 
A simplified textual example of a descriptor file is provided between line 13 of page 24 and line 1 of page 25, and a 
standard XML DTD and schema that describes a format which can be used for a descriptor file is provided between 
line 7 of page 41 and line 17 of page 45. 

12 This is described in various places in the application, including lines 14-15 of page 22, lines 2-20 of page 23, lines 
8-12 of page 25, lines 7-23 of page 30 and lines 13-15 of page 31. 
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defined elements from the network communication into a record,' 3 and to electronically transmit 
the record to a billing system for further processing. 14 



13 Copying the pre-defined elements into a record is described in various portions of the application, including lines 
21-23 of page 13, lines 1-3 of page 17, lines 9-18 of page 25, lines 1-2 of page 26, and lines 3-14 of page 32. 

14 Transmitting an event record to a billing system for further processing is described in, among other places, lines 
23-24 of page 13, lines 17-18 of page 25, lines 4-8 of page 31 and lines 10-14 of page 32. 
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VI. Grounds of Rejection to be Reviewed on Appeal 

A. Whether claims 1-20 are unpatentable under 35 U.S.C. § 102(e) based upon U.S. 
published patent application 2005/0044197 ("Lai"). 
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VII. Arfiument 

A. Claims 1-20 are not properly rejected under 35 U.S.C. § 102(e) as anticipated by 
Lai 

"A claim is anticipated only if each and every element as set forth in the claim is found, 
either expressly or inherently described, in a single prior art reference." 15 The elements must be 
arranged as required by the claim. 16 When an element is asserted to be inherently present in a 
cited reference, the examiner must show that "the allegedly inherent characteristic necessarily 
flows from the teachings of the applied prior art." 17 Further, when determining whether a claim 
is anticipated, "[a] 11 words in a claim must be considered in judging the patentability of that 
claim against the prior art." 18 When considering those words they must be given their broadest 
reasonable interpretation, though that interpretation must be "consistent with the interpretation 
that those skilled in the art would reach." 19 That interpretation can be derived from a variety of 
sources, including the claims themselves, the patent's written description, and reference sources 
such as dictionaries. 20 If a claim is rejected based on an interpretation which is inconsistent with 
the interpretation which would be reached by those skilled in the art, that rejection must be 
reversed. 21 

1. Claims 1,2-3,5-8, 12, 14-15 
The Office did not provide the necessary analysis of the cited art and the claim 
limitations to make out a prima facie case of anticipation for claim 1. In rejecting claim 1, the 
Office simply prefaced claim 1 with the words "Lai discloses" then added references to 
paragraphs 63, 411, 465, 640, 968, 976 and 986 of Lai as supposedly teaching all of the 
limitations of claim 1 22 These referenced paragraphs do not match up with the claim limitations, 

13 Verdegaal Bros. v. Union Oil Co. of California, 814 F.2d 628, 631 (Fed. Cir. 1987). 

16 In re Bond, 910 F.2d 83 1 (Fed. Cir. 1990). 

17 Ex parte Levy, 17 USPQ2d 1461, 1464 (Bd. Pat. App. & Inter. 1990) (emphasis in original). 

18 In re Miller, 441 F.2d 689, 694 (C.C.P.A. 1971). 

19 Manual of Patent Examining Procedure (MPEP) § 21 1 1 citing In re Cortright, 165 F.3d 1353, 1359 (Fed. 
Cir. 1999). 

20 MPEP 21 11.01(111) citing Phillips v. AWH Corp., 415 F.3d 1303 (Fed. Cir. 2005) and Brookhill-Wilk 1, LLC v. 
Intuitive Surgical, Inc., 334 F.3d 1294 (Fed. Cir. 2003). 

21 See, e.g., In re Buszard, 504 F.3d 1364 (Fed. Cir. 2007) (reversing a rejection based on the Office's reliance on an 
incorrect claim interpretation); In re Cortright, 165 F.3d 1353 (Fed. Cir. 1999) (same). 

22 See Office Action at 2. 
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nor do they include any explanation for how the cited portions of Lai teach the limitations of 

claim 1. For example, the Office encased all of the third clause, and half of the fourth clause of 

claim 1 between identical instructions to "(see para 0063, 0411, 0465, 0640, 0968, 0976, 0986)." 

No explanation was provided for why the fourth clause of claim 1 was split in half. No 

explanation was provided for why the first half of the fourth clause was combined with the third 

clause, even though those clauses recite two distinct steps in the method of claim 1. No 

explanation was provided for which aspects of the cited paragraphs (or even which paragraphs) 

supposedly teach the individual limitations of claim l's third and fourth clauses. No explanation 

was provided for how the identified paragraphs which, on average, are separated from one 

another by over 150 paragraphs, even relate to one another. The only exception to the 

unexplained citation to paragraphs 63, 411, 465, 640, 968, 976, and 986 was the citation that 

covered the second half of clause 4, all of clause 5, and the final "wherein" clause for claim 1. In 

that citation, rather than only citing the seven paragraphs identified above, the Office cited those 

same seven paragraphs and claims 8 and 28 of Lai. No explanation was provided for why 

claims 8 and 28 were added to the list of cited sections of Lai, or how any of those claims relates 

either to the individual limitations of claim 1 or to each other. 

This treatment of claim 1 is clearly not sufficient to make out a prima facie case of 

anticipation. It is well established that, during examination, the Office has the responsibility for 

making out a prima facie case of unpatentability. 23 As set forth previously, not only does this 

prima facie case include showing that each element in a claim is present in the cited art, it also 

includes showing that the cited art discloses those elements arranged in the same way as recited 

in the claim. The showing must be explicit, and must be made for each individual limitation in a 

claim. 24 That showing clearly was not made in this case. Instead, this case is analogous to the 

situation addressed by the board in Ex parte Dykes'} 5 

Here, the Examiner has merely directed our attention to an "EJB Type" column in 
Beust and thus has not clearly shown and has left it up to us to speculate as to how 
this column in Beust defines resource references within a session EJB. We can 
only rule on the basis of the evidence that is provided in support of the rejection, 

23 E.g., In re Oetiker, 977 F.2d 1443, 1445 (Fed. Cir. 1992). 

24 E.g., Gechter v. Davidson, 116 F.3d 1454, 1460 (Fed. Cir. 1997) ("to hold that a prior art reference anticipates a 
claim, the Board must expressly find that every limitation in the claim was identically shown in the single 
reference."); see also 37 C.F.R. 1.104(c)(2) ("When a reference is complex or shows or describes inventions other 
than that claimed by the applicant, the particular part relied on must be designated as nearly as practicable. The 
pertinence of each reference, if not apparent, must be clearly explained and each rejected claim specified."). 

25 Appeal no. 2009-007556 (B.P.A.I. 2009). 
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and here we find it deficient. The allocation of burdens requires that the USPTO 
produce the factual basis for its rejection of an application under 35 U.S.C. § 102. 
In re Piasecki, 745 F.2d 1468, 1472 (Fed. Cir. 1984) (citing In re Warner, 379 
F.2d 1011, 1016 (CCPA 1967)). The one who bears the initial burden of 
presenting a prima facie case of unpatentability is the Examiner. In re Oetiker, 
977 F.2d 1443, 1445 (Fed. Cir. 1992). 

Therefore, we find that the Examiner has not set forth a sufficient initial showing 
of anticipation, and we find that Appellants have shown error in the Examiner's 
rejection of claims 2 and 10. Therefore, we reverse the rejection of claims 2 and 
10. Claims 11 and 12 depend from claim 10 and therefore [the rejections of those 
claims] are also reversed. 26 

Accordingly, even if the cited sections of Lai could be pieced together to anticipate the method 

of claim 1 (which, as set forth below, they cannot), the rejection of claim 1 should be reversed, 

because the Office has not made the showing necessary to establish a prima facie case of 

anticipation. 

Substantively, Lai only briefly touches on the concept of billing in a web services 
context, and does not provide any of the details which would be necessary to anticipate claim 1 . 
What Lai does provide is an extremely wide ranging disclosure of issues and technology for 
designing and implementing web services. This disclosure includes such basic information as 
entities that can participate in a web service transaction. 27 It also includes information about 
architectures for web services components, 28 best practices design patterns that can be used to 
address needs such as scalability and reliability, 29 and even how web services can be used for 
integrating applications between enterprises. 30 To the extent Lai addresses billing, it does so 
only to describe how its disclosed technology is compatible with billing functionality. 31 
However, Lai does not disclose the particular steps recited in claim l's method for billing for 
web services. The remarks below illustrate how each of the sections of Lai cited by the Office 
fail to teach claim l's method, which includes steps of creating a descriptor file, and configuring 
a handler to monitor a web service communication for a pre-defined element in that descriptor 
file. 



26 Ex parte Dykes, appeal no. 2009-007556 (B.P.A.I. 2009) at 9-10 (emphasis in original). 

27 E.g., a service requester and a service provider, as disclosed in paragraph 63 of Lai. 

28 £.g, Lai, HI 404, 409 

29 E.g., Lai, IK 524-532. 
30 E.g., Lai, fl 935-36. 

31 See, e.g., Lai, % 640 ("The information captured in the logger may be sufficient for basic usage analysis and per- 
call-based billing."). 
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a. Paragraph 63, and Claims 8 and 28 of Lai 

Paragraph 63, and claims 8 and 28 of Lai explain some foundational concepts of Lai's 
web service technology, but do not address either billing in general, or the steps of claim 1 in 
particular. Paragraph 63 discloses that there can be different kinds of web services, 32 and that 
web services are provided by a "service provider" and accessed by a "service requester." 
Paragraph 63 also discloses that service requesters can be configured to discover service 
providers through a service registry. Claims 8 and 28 recite different layers which can be used to 
organize the web service architecture disclosed in Lai. These layers include a network layer 
which is configured to serve as an underlying network for services, and a transport layer which is 
used for delivering messages between components of a web service. 

The only similarity between the subject sections of Lai and the steps of claim 1 is that 
some words are found in both claim 1 and the subject sections of Lai. For example, claim 1 
recites that a handler is located at either the service requestor or the service provider, and 
paragraph 63 of Lai uses the terms "service requester" and "service provider." Similarly, claim 1 
recites a step of configuring the handler to monitor a web service network communication, and 
claims 8 and 28 of Lai use the term "monitoring" to describe how a management layer is 
configured. However, this superficial verbal similarity does not reflect any substantive similarity 
between the subject sections of Lai and the steps of claim 1. For example, while paragraph 63 of 
Lai uses the terms "service requester" and "service provider," it does not disclose that a handler 
is located at either of those entities, 33 or that such a handler could be configured to monitor a web 
service network communication for a pre-defined element in a descriptor file. 34 Similarly, while 
claims 8 and 28 of Lai use the term "monitoring" to describe the configuration of a management 
layer, those claims do not indicate that what is being monitored is a web service network 
communication between a service requester and a service provider, that the monitoring is for a 
pre-defined element in a descriptor file, or that the monitoring is something a handler is 
configured to do. Given this lack of technical similarity, the applicants submit that paragraph 63 
and claims 8 and 28 from Lai are clearly insufficient to support the rejection of claim 1. 



32 Examples of different types of web services disclosed in paragraph 63 of Lai are business to business web services 
and business to consumer web services. 

33 This is a limitation recited in the final wherein clause of claim 1. 

34 This is recited in the third step of claim 1. 
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b. Paragraphs 411 and 465 of Lai 

Paragraphs 411 and 465 of Lai are part of a large section of that reference which 
discloses a framework and ground rules which can be used to build web services. 35 Paragraph 
411 discloses that web services can be implemented using a "meta-architecture" comprising 
"meta-components" made up of different components and services. Paragraph 465 discloses that 
many web services are stateless beans 36 making remote procedure calls, and that information for 
a session can be stored when a SOAP call is initiated. 

Paragraphs 411 and 465 provide only extremely high level information about 
functionality which may be provided in a system implemented using Lai's technology, and do 
not include any teaching or suggestion of the steps recited in claim 1 . For example, paragraph 
411 of Lai discloses that the "Service Management components provide ... monitoring of the 
service level, and metering the business services for services billing." However, it doesn't 
address specific steps performed in monitoring the service level or metering for services billing, 
or disclose steps which could be performed to set the stage for gathering billing data (e.g., 
creating a descriptor file, or configuring a handler to monitor a web service network 
communication for a pre-defined element in the descriptor file). Similarly, paragraph 465 
discloses that storing information when a SOAP call is initiated can allow "Web Services 
management tools to meter the remote business services for billing or performance-monitoring 
purposes." However, like paragraph 411, paragraph 465 doesn't provide any specific data 
collection steps that are performed as part of that monitoring, or disclose any steps which could 
set the stage for such data collection (let alone the specific steps recited in claim 1). As a result, 
like the passages of Lai discussed in section VILA. La, paragraphs 411 and 465 of Lai simply do 
not include sufficient disclosure to support the rejection of claim 1 . 



35 This section starts on paragraph 400 of Lai, with the heading "Web Services Architecture." Paragraph 41 1 is part 
of the "Architecture Framework" subsection, set forth between paragraphs 408 and 415 of Lai. Paragraph 465 is 
part of the "Upper Platform Layer Principles" subsection, set forth between paragraphs 463 and 466 of Lai. 

36 A "bean" is a reusable program building block that can be combined with other similar blocks in the same or other 
computers in a distributed network to form an application in a Java environment. In standard object oriented 
programming, these building blocks are generally called components. However, keeping with its coffee theme, Sun 
Microsystems referred to these as "beans" when used in Java. See WHAT IS BEAN - DEFINITION FROM WHATIS.COM, 
available at http://searchsoa.techtarget.com/defmition/Bean. 
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c. Paragraph 640 of Lai 

Paragraph 640 is part of a disclosure of a SOAP logger design pattern, 37 which Lai 
indicates can be used to increase the reliability of web services implemented with its 
technology. 38 As with the other sections of Lai, paragraph 640 does not disclose any steps which 
could take place to set the stage for billing data collection, such as creating a descriptor file, or 
configuring a handler to monitor a web service network communication for a pre-defined 
element in the descriptor file. Instead, paragraph 640 of Lai simply states that certain 
information (e.g., date/time) can be logged in the logger, without indicating that that information 
was previously defined in a descriptor file, or that it would be logged by the logger because the 
logger was configured to monitor a web service network communication for the element in the 
descriptor file. Indeed, the primary similarity between paragraph 640 and the method of claim 1 
appears to be that paragraph 640 states that "[t]he information captured in the logger may be 
sufficient for basic usage analysis and per-call-based billing." However, a simple recitation that 
information collected by a component may be sufficient for usage analysis and billing is clearly 
not sufficient to justify a 102 rejection for a claim reciting the specific steps of claim 1. As a 
result, the applicants submit that paragraph 640 of Lai cannot remedy the weaknesses of the 
portions of Lai discussed above in sections VILA. 1. a and VILA. Lb. 

d. Paragraphs 968, 976, and 986 of Lai 

Paragraphs 968, 976 and 986 are part of a larger section of Lai dealing with integrating 
different systems using web services. 39 Paragraph 968 discloses that legacy mainframe systems 
can be connected to web service clients using a Java Connector Architecture in which service 
requests are translated into calls that invoke the functionality of the legacy systems. Paragraph 
976 discloses that, using an enterprise application integration product, business processes can be 
modeled as Process Models, which are series of actions, where specific actions are preferably 



37 The "SOAP Logger Design Pattern" is set forth between paragraphs 630 and 646 of Lai. 

38 See Lai, ^ 529: "Reliability Design Patterns-State management, SOAP logger." 

39 The section starts on paragraph 934 of Lai, with the heading "Enterprise and Cross-Enterprise Integration." 
Paragraphs 968 and 976 are part of the "Cross-Enterprise Integration Framework" subsection, which is set forth 
between paragraphs 965 and 98 1 . Paragraph 986 is part of the "Integration Technologies" subsection, which is set 
forth between paragraphs 982 and 986. 
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taken if certain events take place. Paragraph 976 also discloses that a workflow rule engine can 
manage business rules which describe and execute Process Models when different events take 
place. Paragraph 986 discloses that one of the core components of the Java Connector 
Architecture discussed in paragraph 968 is a Resource Adapter. According to paragraph 986, the 
Resource Adapter provides connectivity between an enterprise's information systems, and a 
client system which allows the client system to invoke the enterprise systems' functionality. 

None of paragraphs 968, 976 and 986 provides any description of web service billing 
data collection, or of the steps from claim 1 discussed previously. Indeed, none of paragraphs 
968, 976 or 986 even mentions billing for web services. The closest any of those paragraphs 
come to claim 1 is they disclose that workflow processes performed by a back end system can be 
monitored for audit purposes. 40 However, the monitoring disclosed in the subject sections of Lai 
is different from the monitoring of claim 1, at least because claim 1 requires configuring a 
handler to monitor a web service network communication between a service requestor and a 
service provider. The workflow processes monitored for audit purposes are not a 
communication between a service requestor and a service provider. Rather, they are acts (such 
as execution of Process Models and triggering of rules which caused the Process Models to be 
executed) which are performed internally by the back end system. Additionally, even if 
monitoring the internal processing of a back end system were treated as monitoring a web 
service network communication between a service requestor and a service provider, there is no 
disclosure anywhere in Lai that what is monitored for is a pre-defined element from a descriptor 
file. Indeed, like the portions of Lai discussed in sections VII.A.l.a-c, paragraphs 968, 976 and 
986 of Lai do not include any disclosure of a descriptor file designating a pre-defined element at 
all. Accordingly, the applicants submit that none of the sections of Lai cited against claim 1 is 
sufficient to make out a prima facie case of anticipation for that claim, and so the rejection of 
claim 1 should be reversed. 

2. Claim 4 

Claim 4 depends from claim 1, and modifies that claim by reciting an additional step of 
transforming the pre-defined element (discussed in section VII.A.l in the context of claim 1) 
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according to a set of instructions in the descriptor file before transmitting the event record (which 
claim 1 recites that a set of instructions is configured to copy the pre-defined element into) to a 
billing system. In the Office Action, claim 4 was rejected using the same approach discussed 
above for claim 1. That is, the Office prefaced claim 4 with the words "Lai discloses" then 
stated "(see para 0063, 0411, 0465, 0640, 0968, 0976, 0986, and claim 8, 28)" after the 
conclusion of the claim. 41 The Office neither provided any explanation to accompany the 
citation of those sections, nor set forth any argument mapping any of those sections to the 
limitations of claim 4. Accordingly, the rejection of claim 4 should be reversed for at least the 
reason that the Office did not make the showing necessary to support a prima facie case of 
anticipation. 

In addition to being insufficient to support the rejection of claim 4 based on its complete 
lack of explanation or mapping of claim elements, the Office's citation of the 9 identified 
sections of Lai is also insufficient because none of those sections teaches or suggests the 
limitations of claim 4. Indeed, the only cited sections of Lai that are even proximate to a 
disclosure which is linguistically similar to claim 4 are paragraphs 411 and 976. However, for 
the reasons set forth below, even those proximate linguistically similar sections are not sufficient 
to justify the rejection of claim 4. 

For paragraph 411, the proximate linguistically similar paragraph is paragraph 412, 
which states that "the relevant Web Services components may process the balance inquiry and 
perform transcoding for different client devices wherever necessary." However, there are at least 
two reasons why this transcoding does not teach or suggest the transformation of claim 4. First, 
claim 4 recites that its transformation is performed according to instructions in claim l's 
descriptor file, and, as is the case with paragraph 411, paragraph 412 does not include any 
teaching or suggestion of claim l's descriptor file. Second, claim 4 recites that what is 
transformed is the pre-defined element that is copied into the event record that is sent to the 
billing system. By contrast, paragraph 412 does not include any disclosure that its transcoded 
data is sent anywhere other than to the client device used by a service requester. 

For claim 976, the proximate linguistically similar paragraph is paragraph 974, which 



40 See Lai, f 968 ("Workflow processes may be monitored with transactions logged for audit purposes."); K 976 
("The current or historic events, Process Model actions, and/or which business rules are fired, may be monitored and 
administered by a Process Monitor for performance and audit purpose."). 

41 Office Action at 3. 
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states that "[a]t the presentation level, if data need to be transformed, developers may use the 
XML Style Sheet Processor (XSLT) to translate and render data into another format, such as 
delimited text, proprietary text format, or PDF." However, this translation and rendering is 
insufficient to teach the limitations of claim 4 for at least the reasons given for the transcoding of 
paragraph 412. First, there is no teaching or suggestion that the XSLT processor performs the 
translation of paragraph 974 according to instructions included in the descriptor file as recited in 
claim 4. Second, the disclosure of paragraph 974 indicates that its transformation is performed 
for the purpose of rendering data, 42 and does not include any indication that what is transformed 
in a pre-defined element that is copied into an event record and sent to a billing system. 
Accordingly, the applicants submit that, as none of the cited sections of Lai are even proximate 
to a disclosure of the limitations of claim 4, the rejection of claim 4 is clearly improper, and 
should be reversed. 



3. Claims 9-10 

Claim 9 depends indirectly from claim 1, and modifies that claim by requiring that 
programmed billing instructions from the billing system are configured to determine whether the 
service requestor is solvent enough to purchase a web service transaction, and to determine 
whether the web service transaction may be performed. As with claim 4, no explanation or 
mapping between prior art and claim elements was provided for the rejection of claim 9. Instead, 
all that was provided was the instruction to "(see para 0063, 041 1, 0465, 0640, 0968, 0976, 0986, 
and claim 8, 28)," 43 which, as set forth in the discussion of claims 1 and 4, is clearly not 
sufficient to make out a prima facie case of anticipation. Further, even ignoring that deficiency, 
the rejection of claim 9 is still not proper, because none of the cited sections of Lai are even 
proximate to any disclosure which has any similarity to the limitations of claim 9. The closest 
any of the cited sections come is paragraph 968, which follows a disclosure that authentication 
and associated entitlement services can be invoked to determine whether a client is a valid user, 
and whether he or she is authorized to access a fund transfer service. 44 However, there is no 
disclosure that those authentication and entitlement services make any determination of the 



42 The fifth edition of the MICROSOFT COMPUTER DICTIONARY (2002, Sandra Haynes and Alex Blanton, eds) to 
"render" means "To produce a graphic image from a data file on an output device such as a video display or 
printer)." MICROSOFT COMPUTER DICTIONARY at 449. 

43 Office Action at 4. 
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user's solvency when deciding whether the user can access the fund transfer service. Instead, 
paragraph 967 indicates that the decision of whether the user can access the fund transfer service 
is based on security (e.g., is the user who he or she purports to be) considerations, rather than 
solvency considerations. Accordingly, the applicants submit that, as none of the cited sections of 
Lai are even proximate to a disclosure of the limitations of claim 9, the rejection of claim 9 is 
clearly improper, and should be reversed. 

4. Claim 11 

Claim 1 1 depends from claim 9, and modifies that claim by reciting that the programmed 
billing instructions discussed in the context of claim 9 are configured to return a response to the 
web service provider indicating a quantity for the web service transaction to proceed. In the 
Office Action, claim 1 1 was given precisely the same treatment as claim 9. That is, it was 
prefaced with "Lai discloses", and then followed with the instruction to "(see para 0063, 0411, 
0465, 0640, 0968, 0976, 0986, and claim 8, 28)." 45 As set forth previously, this approach is 
insufficient to make out a prima facie case of anticipation, and so the rejection of claim 1 1 
should be reversed for at least that reason. However, the rejection of claim 11 is also 
substantively improper. Even if the determination of whether a user can proceed with a fund 
transfer service disclosed in paragraph 967 of Lai is treated as teaching determining whether the 
service requester is solvent enough to purchase a web service transaction, there is no teaching or 
suggestion whatsoever of returning a response indicating a quantity for the web service 
transaction to proceed. Accordingly, the rejection of claim 11 should be reversed, as that 
rejection is both procedurally and substantively improper. 

5. Claim 13 

Claim 13 depends indirectly from claim 1, and modifies that claim by requiring that the 
web service network communication comprises a SOAP message stream, and that the SOAP 
message stream comprises a set of data including "quality of service information, authorization 
key fields, version numbers, encrypted account information, and start/stop time." In rejecting 
claim 13, the Office did not provide any explanation for how any of those types of data are 



14 This disclosure is set forth in paragraph 967, which was not cited by the Office. 
t5 Office Action at 4. 



taught or suggested in the cited art. Instead, as with claims 4 and 9, it simply provided an 
instruction to "see para 0063, 0411, 0465, 0640, 0968, 0976, 0986, and claim 8, 28." 46 As 
discussed previously, that type of unexplained instruction is clearly insufficient to make out a 
prima facie case of anticipation. Further, even if it were not necessary to provide explanation as 
part of the prima facie case, the rejection of claim 13 would still be improper because none of the 
sections of Lai cited by the Office actually teach that claim's SOAP message stream. Indeed, 
only three of the sections cited by the Office, paragraphs 465, 640 and 968, even mention SOAP 
messaging, and none of those sections includes any teaching or suggestion of a SOAP message 
stream which includes the information recited in claim 13, such as quality of service information 
and encrypted account information. Accordingly, the applicants submit that the rejection of 
claim 13 is clearly improper, and should be reversed, as a prima facie case of anticipation has not 
been, and cannot be, made out for that claim. 

6. Claims 16 and 19-20 

Claim 16 is directed to a tangible computer-readable medium having computer 
executable instructions for performing a method comprising: receiving a descriptor file 
designating at least one pre-defined element; utilizing the descriptor file to monitor a web service 
network communication for the predefined element(s); copying the pre-defined element(s) from 
the network communication into a record; and electronically sending the record to a billing 
system for further processing. In rejecting claim 16, the Office simply prefaced claim 16 with 
the words "Lai discloses," then followed it with the instruction to "see para 0063, 0411, 0465, 
0640, 0968, 0976, 0986, and claim 8, 28. " 47 As set forth in the discussion of claim 1, this type of 
instruction is simply insufficient to make out a prima facie case of anticipation. As a result the 
rejection of claim 16 under 35 U.S.C. § 102 should be reversed, because the Office has not made 
the showing necessary for a prima facie case of anticipation. 

However, even if no explanation were necessary to make out a prima facie case of 
anticipation, the rejection of claim 16 would still be improper, because the cited sections of Lai 
do not teach the limitations recited in that claim. For example, claim 16 recites "receiving a 
descriptor file designating at least one pre-defined element" and "utilizing said descriptor file to 



46 Office Action at 4. 

47 Office Action at 5. 
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monitor a web service network communication for said pre-defined element(s)." These steps are 
performed to support eventually sending a record to a billing system for further processing, 
because the pre-defined element(s) are copied from a web service network communication into 
that record. The cited sections of Lai do not include any disclosure of these types of preparatory 
steps. At most, they provide a high level description of how Lai's technology is compatible with 
billing functionality, but they do not include receipt of a descriptor file, or subsequent use of that 
descriptor file in monitoring a web service network communication. Accordingly, the applicants 
submit that claim 16 could not properly be rejected as anticipated by Lai, and so the rejection of 
that claim must be reversed. 

7. Claims 17-18 

Claim 17 is directed to a system for billing for web services which is, in many ways, 
similar to the method of claim 1. For example, claim 17 recites both a descriptor file and a 
handler. Similarly, both claim 17 and claim 1 include limitations that the handler is configured to 
monitor a web service network communication between a service requestor and a service 
provider, and limitations related to transmitting a record (claim 1 uses the term "event record") to 
a billing system for further processing. Of course, there are some differences between the 
claims. For example, claim 17 recites that the handler is configured to "intercept said 
communication if said communication corresponds to said at least one pre-defined element in 
said descriptor file," while claim 1 does not. However, despite those differences, the arguments 
set forth for claim 1 can also be applied to claim 17 to show why the rejection of that claim 
should be reversed. As with the rejection of claim 1, in rejecting claim 17, the Office prefaced 
claim 17 with "Lai discloses" and then added unexplained instructions to "see para 0063, 0411, 
0465, 0640, 0968, 0976, 0986, and claim 8, 28" both within and after the body of the claim. 48 As 
was the case with claim 1, the citations of various portions of Lai in the rejection of claim 17 do 
not match up with the structure of the limitations in the claim, 49 and no explanation was provided 
for what relation any of the cited paragraphs had either to each other or to the claim limitations. 
Similarly, claim 17 also includes limitations which are simply not present in the cited section of 



48 Office Action at 5. 

49 Office Action at 5. In particular, the Office grouped all of the limitations before claim 17's wherein clauses 
together, and combined those limitations with all of claim 17's first wherein clause, and half of its second wherein 
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Lai, including a descriptor file which designates at least one pre-defined elements, and a handler 
which is configured to monitor a web service network communication between a service 
requestor and a service provider, and to intercept the communication if it corresponds to the at 
least one pre-defined element in the descriptor file. 50 As a result, the applicants submit that the 
rejection of claim 17, as well as the rejection of claim 18 which depends therefrom, is clearly 
improper, and should be reversed. 



clause. The remainder claim of claim 17's second wherein clause, and all of its third and fourth wherein clauses 

were then placed in a second group. 

50 Claim 17, first and second wherein clauses. 
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VIII. CLAIMS APPENDIX 

1 . A computerized method for billing for web services comprising the steps of: 

creating a descriptor file designating a pre-defined element; 

storing said descriptor file in a tangible computer readable medium; 

configuring a handler resident on a computer comprising a processor operable to 
execute computer readable instructions to monitor a web service network 
communication, between a service requestor and a service provider, for said 
predefined element in said descriptor file; 

configuring said handler to send said pre-defined element to a set of programmed 
instructions to create an event record, wherein the set of programmed instructions 
is configured to copy the pre-defined element from the network communication 
into the event record; 

electronically transmitting said event record to a billing system for further 
processing; 

wherein the handler configured to monitor for said predefined element in said descriptor 
file is located at an entity taken from the list of entities consisting of: 

a) the service requestor; and 

b) the service provider. 

2. A computerized method as claimed in claim 1 wherein said programmed instructions are 
configured to determine whether an event corresponding to said event record requires 
authorization. 
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3. A computerized method as claimed in claim 1 wherein said programmed instructions are 
configured to determine whether an event corresponding to said event record requires 
rating. 

4. A computerized method as claimed in claim 1 further comprising: transforming said pre- 
defined element according to a set of instructions in said descriptor file before 
transmitting said event record to the billing system. 

5. A computerized method as claimed in claim 1 wherein said web service network 
communication comprises a request for a web service and a response to said request 
wherein said request comprises a start time and said response comprises an end time and 
further comprising the steps of: 

creating a first event record comprising said start time; 

sending said first event record to said billing system; 

queuing said first event record in said billing system; 

creating a second event record comprising said end time; 

sending said second event record to said billing system; 

matching said first event record with said second event record; 

calculating a charge for said web service based on said start time and said end 
time; 

returning said charge to said service provider. 
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6. A computerized method as claimed in claim 1 wherein said billing system comprises 
programmed billing instructions coded to determine whether a web service transaction 
may be performed. 

7. A computerized method as claimed in claim 6 wherein said programmed billing 
instructions are configured to determine if said service requestor is permitted to access 
said web service transaction. 

8. A computerized method as claimed in claim 7 wherein said billing system returns a 
response to said web service provider indicating whether said web service transaction 
should proceed. 

9. A computerized method as claimed in claim 6 wherein said programmed billing 
instructions are configured to determine whether said service requestor is solvent enough 
to purchase said web service transaction. 

10. A computerized method as claimed in claim 9 wherein said programmed billing 
instructions are configured to return a response to a set of application code associated 
with said web service provider indicating whether said web service transaction should 
proceed. 

11. A computerized method as claimed in claim 9 wherein said programmed billing 
instructions are configured to return a response to said web service provider indicating a 
quantity for said web service transaction to proceed. 

12. A computerized method as claimed in claim 1 wherein said web service network 
communication comprises a SOAP message stream; wherein the service requestor 
accesses the service provider on a direct peer-to-peer basis; and wherein the handler is 
located at the service provider. 
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13. A computerized method as claimed in claim 12 wherein said SOAP message stream 
comprises a set of data including quality of service information, authorization key fields, 
version numbers, encrypted account information, and start/stop time. 

14. A computerized method as claimed in claim 12 wherein said billing system uses said pre- 
defined element in said SOAP message stream to support at least one pre-defined billing 
plan. 

15. A computerized method as claimed in claim 14 wherein said pre-defined billing plans is 
chosen from a list consisting of subscriptions, bundled plans, time-based usage plans, re- 
occurring charges, one-time charges, discount plans based on usage, discount plans based 
on time-of-day, discount plans based on customer loyalty, discount plans based on 
family/organization relationships, tiered plans, location dependent pricing, and 
combinations thereof. 

16. A tangible computer-readable medium having computer executable instructions for 
performing a method comprising 

receiving a descriptor file designating at least one pre-defined element; 

utilizing said descriptor file to monitor a web service network communication for 
said pre-defined element(s); 

copying said-predefined element(s) from said network communication into a 
record; 

electronically sending said record to a billing system for further processing. 

17. A system for billing for web services comprising: 

a descriptor file; 



27 



a handler; 
a record; and 
a billing system 
wherein 

said descriptor file designates at least one pre-defined elements; 

said handler is configured to monitor a web service network communication, 
between a service requestor and a service provider, and to intercept said 
communication if said communication corresponds to said at least one pre-defined 
element in said descriptor file; 

said handler is further configured to copy said pre-defined elements from said 
network communication into a record; 

said handler is further configured to electronically transmit said record to a billing 
system for further processing. 

The system of claim 17 wherein said billing system is embedded within a web service 
server; wherein said further processing comprises determining whether said service 
requestor is solvent enough to purchase a web service corresponding to said web service 
network communication; wherein said web service network communication comprises a 
SOAP message stream; wherein said handler is located at the service provider; and 
wherein the service requestor accesses the service provider on a direct peer-to-peer basis. 
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19. The computer readable medium of claim 16, wherein the monitored web service network 
communication is between a service requestor and a service provider, and wherein the 
computer readable medium is located at the service provider. 



20. The computer readable medium of claim 19, wherein the web service network 
communication comprises a communication where the service requestor accesses the 
service provider on a direct peer-to-peer basis. 



29 



EVIDENCE APPENDIX 
None. 



RELATED PROCEEDINGS APPENDIX 
None. 
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XI. CONCLUSION 

In light of the foregoing, the appellants request that each of the pending rejections be 

reversed, and that the pending claims be allowed in their present form. 

The Commissioner for Patents is hereby authorized to charge any deficiency or credit any 
overpayment of fees to Frost Brown Todd LLC Deposit Account No. 06-2226. 



Respectfully submitted, 
Robert Birch, et al. 

By /William S. Morriss/ 

William S. Morriss Reg. No. 60,477 

Attorney for Applicants 

FROST BROWN TODD LLC 

2200 PNC Center 

201 East Fifth Street 

Cincinnati, Ohio 45202 

(513) 651-6915 
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